1. version control is useful, really!
2. git is a simple version control system
   
3. how to get started using git for our personal work

we might learn later

• how to fix version conflicts
• how to develop workflows
• how git can be used to collaborate

• know what you did and when you did it!
• documentation & development history
• do robust, structured backups!

reproducibility

• don't go back and forth!
• manage your non-linear development!
• write re-usable code!

progressive development

• collaborate on code and text!
• enable structured code review
• publish your code

openness

(kind of)

• There are so many files!

• Which one was the latest version?
• OMG, I can show that to no one!

• Did I fix that bug in the right file now?
  
• What version of that function is this?
  
• Which version of the code was used to produce this result?

• I still need to do manual back-ups!
  
• I still cannot reproduce what I did!

• it's a version control “system”
• robust against errors
• transparent structure
• platform independent
• git works for writing, too!
• geeky command line

$ git push origin master

• or user-friendly graphical software

{demo}

• it's a directory
• it contains meta-data
  
• it contains 'commits'
  

• instructions to change one file or multiple files
• instructions to remove or add files

• each commit has a unique name: a hash-tag #5b26a8379e0f1ea6dd87916d738a49d118361676
• meta info:
  • commiter name and e-mail, time and date of commit
  • a commit message
  • a reference to it's parent (pointer)

• a reference to a commit
• a reference to another pointer
• they connect commits 'upstream'

Types of pointers:

• 'tags'
• 'branches'
• the 'HEAD' of your repository
  (i.e. the working directory!)

• a repository basically consists of commits.
• each commit has a pointer to it's parent
• HEAD defines the working directory content

• a repository consists of commits.
• each commit has a pointer to it's parent
• HEAD defines the working directory content

• a repository consists of commits.
• each commit has a pointer to it's parent
• HEAD defines the working directory content

• a repository consists of commits
• each commit has a pointer to it's parent
• HEAD defines the working directory content

a directory with files
showing the accumulated commits at 'HEAD'

And this is how 'time travelling' works:
you can move HEAD to branches

And this is how 'time travelling' works:
you can move HEAD to tags

And this is how 'time travelling' works:
you can move HEAD back to 'master' branch

And this is how 'time travelling' works:
you can move HEAD to any commit (per hash-tag)

What you need to learn:

• get startet (Exercise 1)
  • how to create a repository
  • how to build a commit
• time travelling (Exercise 2)
  • how to set tags
  • how to move your HEAD
• how to back-up or sync (Exercise 3)
  • configure remotes
  • push and pull

1. create a git repository
2. generate content
3. do commits

open a terminal

$

Create a new folder.

$ mkdir test
$ cd test
$

Initialise a git repository.

$ mkdir test
$ cd test
$ git init
Initialized empty Git repository ...
$

• create a text file (e.g., test.txt)
• create/copy a code file
• …

check the status!

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        test.txt

nothing added to commit but untracked files present (use "git add" to track)

This is a two step process:

1. staging files for next commit

   $ git add test.txt
   

   • chose files or edits for the next commit
   • wrap 'meaningful' commits

2. commit to repository

$ git commit -m "edit test.txt: fix #23"

• commit message is obligatory: -m "..."

check status again!

$ git status
On branch master
nothing to commit, working directory clean

have a look at your repository tree!

$ git log
commit a9b0697265feb5013eced9c1befb9a10a94a66cb
Author: Florian Schneider <florian.schneider@univ-montp2.fr>
Date:   Fri Nov 21 16:30:53 2014 +0100

    edit test.txt

1. create a git repository
2. edit content
3. do commits

(repeat 2 & 3 a couple of times! use git status and git log!)

in same repository:

1. add a 'tag'
2. edit content
3. add and commit
4. check history: git log
5. checkout tag
6. return to latest version

Terminal:

$ git tag -a v1.0 -m "first version of project"
$

continue work:

• edit
• add and commit

$ git tag
v1.0
$

$ git tag
v1.0
$ git checkout v1.0
$

look at your files!

$ git tag
v1.0
$ git checkout v1.0
$ git checkout master
$

look at your files!

what you learned:

• create a new repository
• add and commit
• check log and status
• add 'tags' as references
• check-out different commits

• Windows: GitHub for Windows
• Mac: GitHub for Mac
• Linux: git-cola
• all: smartGitHg, GitEye, RStudio and other IDEs have plug-ins

and many more: http://git-scm.com/downloads/guis

• back-up
• syncing your computers
• collaboration

• you can clone existing repositories from remotes

git clone https://github.com/cascade-wp6/git_intro.git

• your local repository will refer to the original repository as origin
• you can pull from and push to origin:

git pull origin master
git push origin master

more info: http://git-scm.com/book

https://gitlab.info-ufr.univ-montp2.fr/

• no third party, non-commercial
• hosting of remote repositories
• free private or public projects
• collaborate (teams, tasks)

https://github.com/

• hosting of remote repositories
• free for open source projects (fully public!)
• private repositories (commercial)
• collaborate (issues, teams, access control)
• manage projects (milestones, wikis)

Bitbucket (free private for small teams)

GitLab Cloud (unlimited free private)

self-hosted git server, and many more

1. create a git repository on Gitlab or Github.
2. clone to local Computer:
   git clone https://github.com/user/repo
3. generate content
4. add and commit
5. push (requires password)
6. edit online
7. pull

https://www.atlassian.com/git/

http://git-scm.com/book/

http://git-scm.com/

https://training.github.com/kit/

• turn private repos public!
• choose a license: GPL or MIT for code, Creative Commons for text and data

Why?

• scientific work is public property
• speeding up science: enable re-use & inspiration
• adds credibility and originality
• reproducibility